1. Field of the Invention
This invention generally relates to printer driver software and, more particularly, to a print driver with a user interface for building a print container that preserves separate elements.
2. Description of the Related Art
Conventional methods exist for combining print containers into a single print container. Applications such as SharpDesk™ allow the user to print any document and save the resulting commands as a print container (i.e., a SharpDesk™ document). SharpDesk™ then allows the user to view all such print containers. A useful function in SharpDesk™ consists of combining the print containers into new print containers. This function allows a user to combine related print containers into a single print container that can be printed or sent as email or used in many in document management functions.
More generally, each act of printing involves a single application printing a single document producing a single print container. Normally, the act of printing streams the print container to a spooler or directly to the printer, and the print container is not available to the user. However, most OSs include a “Print to File” capability that saves the print container. To clarify, some terms are presented that are derived from the XML Paper Specification (XPS). For example, the act of printing a single document in an application produces a print container with a single fixed document that include the print commands for rendering the pages in that document. The fixed document contains fixed pages, or the print commands that render each page. Hence, a print container contains only the print commands pertaining to a single fixed document, so the print container is described as a print document. One problem with the merged print container is the loss of distinct fixed documents used to create the merged print container.
An additional issue is the merging of print settings. Print settings are values that affect the way the print commands are executed, for example, landscape vs portrait, 1 up vs 2 up, etc. Conventionally (e.g., GDI printing), print settings are applied at the beginning of the print document, and occasionally as special commands in between pages (resetDC). With this scheme, creating a merged print container by appending a print document involves inserting a resetDC before the new pages are added.
Merging applications strip most of the print settings, except for crucial ones, such as portrait vs landscape. Hence, the merger of multiple print containers into a print container is usually consistent with the print document format built into the OS: the print container contains fixed pages with no distinction of the original print container, and the print settings are a series of resetDCs, again not tied to the original print container.
Another issue in conventional printing is that electronic documents often appear one way when viewed on a monitor screen and another way when printed. Further, many documents depend on locally installed software, fonts, and other resources. When a document is viewed on different computers, aspects of the document, such as page layout, image color, and font style, can change, altering the document's appearance. Consequently, a document's appearance depends greatly on where and how the document is viewed.
The appearance of the printed version of a document can also vary, depending on the printer used. Unfortunately, there is no guarantee that users with different printers attached to different machines will see the exact same document printed on paper as when the document is viewed on the monitor screen.
The above-mentioned issues are being addressed with a document technology called the XML Paper Specification (XPS). This specification is designed to provide users with a consistent document appearance regardless of where and how the document is viewed, and also supports a new document structure for distribution and archiving. This new document structure can include documents created by different applications, all gathered into a single XPS file called a ‘container’. The problem is that, at present, there is no convenient way to combine a set of such documents into a single XPS container (file).
In addition, the included set of documents may exist in a variety of application formats, each requiring conversion to the XPS (XML) document format if the user wants to maintain the XPS container as an archival, distributable entity.
Currently, it is possible to construct, manually, an XPS container containing a mix of application derived documents. However, the task is awkward and subject to errors. Also, doing this task manually makes the inclusion of print tickets for the entire container (job level), the specific documents (document level), and within specific sections of a specific document difficult to accomplish. It is also unclear whether Microsoft™ will support adding documents from non-Microsoft applications, although, XPS supports having such a mix of documents.
Lastly, it is unclear whether such capability will include accessing specific files within the XPS container, to add print ticket options without the applications used to originally create the documents.
XPS Documents maintain a consistent appearance for documents—despite environmental variables—through the use of a fixed page layout. XPS Documents are fixed-format documents described by an XML-based language. This means the document layout is fixed, just as it would be if it were printed on a piece of paper. As a result, an XPS viewer and the XPS print path can present the document in the same way to the user, whether it is viewed in a window or on a piece of paper. Custom resources and other application-specific metadata can also be included in an XPS Document, allowing applications to create and use XPS document packages. Unlike other file formats, an XPS container files can be stored and archived with all the content and design details in tact. XPS document packages describe their contents using a plain-text, XML-based data format, as opposed to a proprietary binary format.
Intended as the replacement for the Enhanced Metafile (EMF) format which was the previously used print spooler format in the GDI print path, the XPS document format is the same as the spooler format used in the XPS print path. It serves as the page description language (PDL) for printers. For printers supporting XPS, this eliminates an intermediate conversion to a printer-specific language, increasing the reliability and fidelity of the printed output. The document format consists of structured XML markup that defines the layout of a document and the visual appearance of each page, along with rendering rules for distributing, archiving, rendering, processing and printing the documents. Notably, the markup language for XPS is a subset of XAML, allowing it to incorporate vector-graphic elements in documents, using XAML to mark up the WPF primitives. The elements used are described in terms of paths and other geometrical primitives.
The XPS Document package is a compressed ZIP archive that allows the resulting file to regain some of the space efficiency that is lost by using an XML-based language. The XPS Document package complies with the Open Packaging Conventions.
XPS Documents are stored in a file, called a package, composed of a set of document components, known as parts. A package has a physical and a logical organization. The physical organization consists of the document parts and folders inside the package, and the logical organization is a hierarchy described by the document parts. The XML Paper Specification applies a specific organization and naming convention to the logical layer for XPS documents.
The parts of an XPS document are organized in a logical hierarchy with the FixedDocumentSequence part at the top. An XPS document package may contain more than one document and the sequence of these documents is described by the FixedDocumentSequence part. The FixedDocumentSequence part references the FixedDocument parts that, in turn, reference the pages of each document within the package.
Each FixedDocument part references the pages of that document as FixedPage parts. Each FixedPage part contains the text markup and layout of a page in the document as well as references to images, fonts, and other custom resources used in the page. Resources such as images and fonts are stored in the package but outside of the FixedPage part, allowing them to be shared by other pages. This is especially useful for font resources, but it could also be useful for any image resources that are used on more than one page, such as a watermark or letterhead logo.
FIG. 1 is a diagram depicting the logical hierarchy of an XPS document (prior art). This example shows the contents of a package that contains two separate documents, each containing two pages. The package in this example could be a presentation where FixedDocument_1 contains the slides while FixedDocument_2 contains the background information.
It would be advantageous if the XPS print container concept could be generalized, so as not to depend on particular protocols and operating systems.
It would be advantageous if a print container could be organized to hold separate document elements.